Hi @polybeandip, thanks for getting this going! Since you are knee deep in this stuff, I would like to tack on a quick request that should be easy to handle. @parthsarkar17 is interested in adding some queue-ey stuff to his benchmarking suite that optimize FSMs and such. Could you please pass him designs for one or two of our more complicated tree schedulers? For each design, he'll need a .futil file, a .data file, and a .expect file.

Some candidates that come to mind:

• Cassandra did up a "complex tree" that uses only rr and strict but has height of 2 or 3.
• Some of your newest implementations of schedulers using stable binary heaps.

UPDATE on our benchmarks

cycles.sh generates cycle counts for all our designs. Remember to run gen_test_data.sh first!

For now, I've also reported this data in cycles.txt and below:

binheap/binheap_test.py: 750
binheap/fifo_test.py: 1509164
binheap/pifo_test.py: 1784719
binheap/round_robin/rr_2flow_test.py: 1870740
binheap/round_robin/rr_3flow_test.py: 1884450
binheap/round_robin/rr_4flow_test.py: 1897807
binheap/round_robin/rr_5flow_test.py: 1903303
binheap/round_robin/rr_6flow_test.py: 1934811
binheap/round_robin/rr_7flow_test.py: 1944544
binheap/stable_binheap_test.py: 1802173
binheap/strict/strict_2flow_test.py: 1785391
binheap/strict/strict_3flow_test.py: 1826179
binheap/strict/strict_4flow_test.py: 1842823
binheap/strict/strict_5flow_test.py: 1852314
binheap/strict/strict_6flow_test.py: 1851588
complex_tree_test.py: 1504412
fifo_test.py: 595422
pifo_tree_test.py: 1199525
round_robin/rr_2flow_test.py: 993313
round_robin/rr_3flow_test.py: 1013489
round_robin/rr_4flow_test.py: 1032869
round_robin/rr_5flow_test.py: 1051211
round_robin/rr_6flow_test.py: 1125919
round_robin/rr_7flow_test.py: 1136933
sdn_test.py: 1244054
strict/strict_2flow_test.py: 1058077
strict/strict_3flow_test.py: 1144637
strict/strict_4flow_test.py: 1233029
strict/strict_5flow_test.py: 1315433
strict/strict_6flow_test.py: 1481437

It looks like @csziklai's PIFOs do about about 300,000 to 1,000,000 cycles better than the binary heaps!

!! Please tell the channel!

It looks like @csziklai's PIFOs do about about 300,000 to 1,000,000 cycles better than the binary heaps!

This sounds awesome but I would caution against celebrating the numbers too much without synthesis results. Something that is takes 1,000,000 cycles at 100MHz is still way faster than something that take 100,000 cycles at 1MHz.

Agreed! Synthesis results are coming up shortly

UPDATE on our synthesis results

resources.sh generates "executive summaries" of the synthesis reports for all our designs: i.e. the output of

fud e --to resource-estimate <filename>.futil

for all our queues. Notably, this means our results (resources.txt) are missing certain stats (for example, BRAMs) and use the default .xdc file: i.e. a clock period of 7 ns. Per @sampsyo's suggestion, this frequency should be okay for now.

@anshumanmohan I think it would be odd to commit counts.txt and resources.txt — I've only added them to show folks reviewing this PR the results. As for where they should live, I'm thinking we make a discussion thread in the packet scheduling repo and park it there. Perhaps that thread could be a running log of synthesis results and cycles counts as we continue tweaking our designs?

Pretty pictures!

Notably, this means our results (resources.txt) are missing certain stats (for example, BRAMs) and use the default .xdc file: i.e. a clock period of 7 ns. Per @sampsyo's suggestion, this frequency should be okay for now.

Thanks for running synthesis @polybeandip! The frequency number you want to report is going to be determined using "worst_slack". You can calculate the best frequency using best_freq = 1000/(7 - worst_slack) MHz. In general, you want compare the product cycle_count * best_freq to determine which design is better.

Ah, perfect! I'll crunch those numbers soon

As for where they should live, I'm thinking we make a discussion thread in the packet scheduling repo and park it there. Perhaps that thread could be a running log of synthesis results and cycles counts as we continue tweaking our designs?

Agreed, thank you!

More graphs, this time using @rachitnigam's suggestion to compute total time spent on our workload. This way, we account for difference in clock speed.

@polybeandip so @ayakayorihiro has the same request as Parth! Would you mind sending her the same things?